looks like IBM introduced an dxl parser defect in this build 9.6.1.7

can anyone else confirm what I'm seeing? Thank you. 

/**********************************
        permission (recursive)
***********************************/
string permission (Permission p){
  string returned = ""
  if (p & read    == read   ) returned = returned "R"
  if (p & modify  == modify ) returned = returned "M"
  if (p & create  == create ) returned = returned "C"
  //if (p & delete  == delete ) returned = returned "D" -> this should work, looks like IBM introduced an dxl parser defect in this build 9.6.1.7
  if (p & (Permission (delete))  == delete ) returned = returned "D"
  if (p & control == control) returned = returned "A"
  if (returned    == ""     ) returned = "none"
  return returned
}//End permission.

Permission all = read|create|delete|modify|control
print permission(all)

 


EHcnck - Fri Dec 16 13:13:43 EST 2016

Re: looks like IBM introduced an dxl parser defect in this build 9.6.1.7
Mathias Mamsch - Sun Dec 18 11:24:36 EST 2016

I noticed that ANY delete (read, modify, etc) function declared on non global DXL level will shadow (make invisible) the DXL perms defined on global level. Chances are, that inside your DXL you have a delete(...) function declared somewhere. It is a parser problem that has existed already in DOORS 8.

As a workaround you can explicitly typecast as you did ... We also found that using braces "()" will make the parser recognize the function. I.e. 

if (p & delete()) returned = return "D"

As a workaround I can only suggest, to not declare any function with the same name as a parameter less function on global level. We also had posts about this on the forum.

Regards, Mathias

Re: looks like IBM introduced an dxl parser defect in this build 9.6.1.7
EHcnck - Sun Dec 18 11:54:22 EST 2016

Mathias Mamsch - Sun Dec 18 11:24:36 EST 2016

I noticed that ANY delete (read, modify, etc) function declared on non global DXL level will shadow (make invisible) the DXL perms defined on global level. Chances are, that inside your DXL you have a delete(...) function declared somewhere. It is a parser problem that has existed already in DOORS 8.

As a workaround you can explicitly typecast as you did ... We also found that using braces "()" will make the parser recognize the function. I.e. 

if (p & delete()) returned = return "D"

As a workaround I can only suggest, to not declare any function with the same name as a parameter less function on global level. We also had posts about this on the forum.

Regards, Mathias

I'm not overloading the delete function I'm running the exact code posted.

Re: looks like IBM introduced an dxl parser defect in this build 9.6.1.7
Mathias Mamsch - Sun Dec 18 12:01:42 EST 2016

EHcnck - Sun Dec 18 11:54:22 EST 2016

I'm not overloading the delete function I'm running the exact code posted.

Then they may have introduced a delete function themself on non global DXL level somewhere inside the interpreter. Can be hard to find. I cannot check, since I do not have DOORS 9.6.1.7 ... Someone else needs to chime in here. If you are sure, that there is nothing on your client loaded somewhere, I would file a PR to IBM. Changes like these are unnecessary. Regards, Mathias